Correções e Documentações do Projeto - #214

…endUrl

Co-Authored-By: Claude Opus 4.8 <[email protected]>

…getMailProvider

Co-Authored-By: Claude Opus 4.8 <[email protected]>

Co-Authored-By: Claude Opus 4.8 <[email protected]>

Co-Authored-By: Claude Opus 4.8 <[email protected]>

…a e enqueue com retry

Co-Authored-By: Claude Opus 4.8 <[email protected]>

…acha via provider

Co-Authored-By: Claude Opus 4.8 <[email protected]>

…e sendWelcome

Co-Authored-By: Claude Opus 4.8 <[email protected]>

…utdown

Co-Authored-By: Claude Opus 4.8 <[email protected]>

…luxo

Co-Authored-By: Claude Opus 4.8 <[email protected]>

…es/providers

Co-Authored-By: Claude Opus 4.8 <[email protected]>

Co-Authored-By: Claude Opus 4.8 <[email protected]>

…stes

# Correção do Campo Telefone

## Problema

Atualmente o campo **Telefone** aceita valores inválidos, por exemplo:

```
+55 1891898989989999
```

Esse valor **não deveria ser aceito**.

A implementação atual não respeita o padrão brasileiro de telefonia nem
limita corretamente a quantidade de dígitos.

---

# Objetivo

Corrigir completamente o campo Telefone para seguir o padrão brasileiro.

O campo **continua sendo opcional**, porém, quando preenchido, deve
aceitar **apenas números válidos**.

---

# Formatos aceitos

## Celular

Formato:

```
(XX) 9XXXX-XXXX
```

Quantidade de dígitos:

- DDD: 2
- Número: 9 dígitos

Total:

```
11 dígitos
```

Exemplos válidos:

```
(11) 91234-5678
11912345678
+55 (11) 91234-5678
+55 11 91234-5678
```

---

## Telefone Fixo

Formato:

```
(XX) XXXX-XXXX
```

Quantidade de dígitos:

```
10 dígitos
```

Exemplos válidos:

```
(11) 3456-7890
1134567890
+55 (11) 3456-7890
```

---

# Formatos inválidos

Os seguintes exemplos devem ser rejeitados:

```
+55 1891898989989999
111
999999999999999999999
abcdefgh
+551234567890123456
+44 11111111111
(11) 999999999999
```

Também não aceitar:

- quantidade maior de dígitos
- quantidade menor de dígitos
- DDD inválido
- DDI diferente de +55
- múltiplos sinais "+"
- caracteres inválidos

---

# Máscara

Aplicar máscara automaticamente enquanto o usuário digita.

Exemplos

Entrada:

```
11912345678
```

Saída:

```
(11) 91234-5678
```

Entrada:

```
1134567890
```

Saída:

```
(11) 3456-7890
```

Entrada:

```
5511912345678
```

Saída:

```
+55 (11) 91234-5678
```

---

# Limite de caracteres

Após remover toda a formatação:

Celular:

```
11 dígitos
```

Fixo:

```
10 dígitos
```

Internacional:

```
+55
```

seguido de

```
10 ou 11 dígitos
```

Não permitir continuar digitando após atingir o limite.

Também configurar corretamente o `maxLength` considerando a máscara.

---

# Fluxo de validação

A validação **não deve depender apenas da Regex**.

Executar as seguintes etapas:

1. Remover espaços.
2. Remover parênteses.
3. Remover hífen.
4. Remover caracteres da máscara.
5. Validar DDI.
6. Validar DDD.
7. Validar quantidade exata de dígitos.
8. Aplicar Regex.
9. Persistir o valor apenas se todas as validações forem aprovadas.

---

# Implementação

Verificar se existe:

- máscara de input
- formatter
- parser
- onChange
- transform
- schema (Zod, Yup, Joi, etc.)

A implementação deve impedir que o usuário digite além do limite
permitido.

---

# Critérios de aceite

- Campo continua opcional.
- Máscara aplicada automaticamente.
- Limite máximo de caracteres respeitado.
- Não permite números maiores que o padrão.
- Não permite números menores que o padrão.
- Aceita apenas telefones brasileiros válidos.
- Aceita celular e telefone fixo.
- Aceita DDI +55.
- Rejeita qualquer outro DDI.
- Exibe mensagem de erro apenas quando um telefone informado for
inválido.
- Não gera regressões em outros formulários.

…testes (#213)

# Documentação de desenvolvimento local e padrão de testes automatizados

## Objetivo

Criar uma documentação para facilitar o onboarding de novos
contribuidores no projeto, centralizando informações sobre execução
local da aplicação e o padrão utilizado para criação de testes
automatizados.

## O que foi alterado

Foi criada uma documentação contendo:

### Desenvolvimento local

- Pré-requisitos necessários para executar o projeto.
- Configuração inicial do ambiente.
- Instalação das dependências.
- Configuração das variáveis de ambiente.
- Comandos utilizados para executar os serviços localmente.
- Orientações para execução e validação da aplicação.

### Padrão de testes automatizados

Foi documentado o padrão utilizado no projeto para organização de testes
utilizando:

- TP (Test Plan)
- TC (Test Case)

A documentação explica:

- Diferença entre TP e TC.
- Como estruturar cenários de teste.
- Como criar novos casos de teste.
- Boas práticas para testes unitários.
- Quando utilizar `it.each`.
- A importância de validar comportamento e regras do sistema, evitando
testes acoplados a detalhes de implementação.

## Exemplo utilizado

Foi utilizado como referência o fluxo de testes do Go Scraper:

…dulo-email

…odulo-email

## Descrição
Introduz o módulo de e-mail transacional centralizado do backend: uma
API interna única (`EmailService`) que enfileira envios de forma
assíncrona e resiliente via BullMQ/Valkey, com worker in-process que
renderiza templates (react-email) e despacha por um provider trocável
(Resend em produção, Noop quando não há credencial). Entrega o e-mail de
boas-vindas como primeiro consumidor real, disparado tanto no registro
por e-mail/senha quanto no primeiro login social (Google, GitHub e
LinkedIn) — apenas quando a conta é criada pela primeira vez
(relogin/vínculo de provider não reenviam). O envio nunca derruba o
fluxo de origem: falhas são apenas logadas. Inclui envs, documentação e
artefatos spec-driven do módulo, e adota o novo nome do projeto
("Candidate") na mensagem de boas-vindas.

## Linear link

https://linear.app/tatame/issue/PAV-76/modulo-de-e-mail-sistema-centralizado-de-envio

## Como foi testado
Testes unitários passando — Backend: 550/550 | Frontend: 320/320